Various input devices are available that permit a computer user to communicate with a computer. A typical personal computer offers input devices such as a keyboard and a mouse. Numerous other devices are available, such as drawing pads, joysticks, and steering wheels (for use with driving games). These devices can be connected to a computer, and they permit the user to communicate information to the computer; the information communicated instructs software applications running on the computer to perform specified actions.
Ideally, a computer user loads a software application, connects an appropriate device to the computer, and the device and software work together without further configuration by the user. This ideal, however, has not been realized in prior systems.
In order for a device to work with a given software application, there must be a defined relationship between the controls on the device and actions that the software application performs. However, there are few standards governing the way in which this relationship is defined. Traditionally, software developers design software applications to support the most common devices and to provide a device mapping control panel for those users who own other devices. This approach, however, has drawbacks: A software developer who wants to design an application to work well with many devices must know what controls are available on each device (e.g., buttons, levers, etc.) and how the device notifies the computer system of operational events (e.g., an input of 1001 signifies the pressing of a button). Additionally, the software developer must make design decisions as to which devices the software will support, and, on those devices that will be supported, how the controls will map to the actions that the software performs. This is a labor-intensive process for the software developer. Moreover, if a user owns an unsupported device, the user must generally resort to mapping the unsupported device manually by referring to generic pictures and tables in an application's manual and using the device mapping control panel provided with the application. This is a notoriously difficult process.
Some input device manufacturers address the problem of ensuring that specific applications work well with the device by supplying a software component with the device that dynamically reconfigures the device based on guesses as to what actions the application expects the device to support. Some manufacturers of devices with newer features provide filters to accommodate existing applications; frequently, these filters simulate keyboard presses or mouse movements for games that do not recognize enhanced features of the new device. Alternatively, some devices are supplied with mapping software that detects the presence of certain applications on the system and configures the device to work better with those applications. However, these ad hoc approaches are error prone, may result in a relationship between device controls and software actions that feels unnatural to the user, and can only provide support for applications the device manufacturer knows about and chooses to support.
The Human Interface Device (HID) standard, defined in conjunction with the Universal Serial Bus (USB) standard, addresses problems such as these. Using HID, an input device can store information about its controls. This information can be obtained by a requesting application program.
HID data generally describes the characteristics of device controls and the format of data generated by the controls. In addition, HID allows different labels or “usages” to be assigned to the controls of an input device. For example, a button might be designated as a “fire” button, as “button1”, “button2,” etc. In addition, HID can include “aliases” for a control. A given control might have a plurality of aliases such as “button1,” “fire,” “torpedo,” etc.
Usages and aliases, if used in a uniform and agreed upon way, provide useful hints about how to use a certain control on an input device. In some cases, for instance, the “fire” button will have an obviously corresponding action in an application program. In other cases, however, the usages and aliases might not correspond directly to any terminology known by the application program.
A further complicating factor is that there is no agreed upon standard for naming HID controls. Even if there were such a standard, it would remain—in may cases—a very difficult task for an application program to determine an optimum set of mappings between numerous input device controls and the actions available in the application program. A determination such as this would require a complex algorithm, tailored specifically for the application program.
The difficulty lies not in finding a workable control for a particular action, but in assigning a combination of controls to a combination of desired actions. For example, any number of controls might work for a “drop bomb” action: a “button1,” a “button2,” a “fire” button,” a “trigger” button, etc. However, assigning the combination of these controls to a combination of different actions, such as “drop bomb,” “start engine,” “lower flaps,” and “zoom” can be much more difficult. The task is actually made more difficult by the use of numerous aliases for each control—each control might duplicate the same aliases.
Accordingly, even with HID devices it is difficult for an application program to determine desirable control/action mappings for unanticipated input devices—input devices for which the application program does not have a pre-defined assignment of controls. The system described below solves this problem.